home *** CD-ROM | disk | FTP | other *** search
/ By Popular Request 2.0 / By Popular Request 2.0 (Arsenal Computer).ISO / amiga_5 / pin391bs.lha / pine3.91 / imap / IMAP2bis.TXT next >
Text File  |  1992-12-12  |  38KB  |  899 lines
  1. *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         M. Crispin
  8. Request for Comments: ????                                    Washington
  9. Extends: RFC 1176                                          December 1992
  10.  
  11.  
  12.               IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC defines optional extensions to the IMAP2 procotol for
  18.    multi-part textual and non-textual Internet messages as per the
  19.    Internet DRAFT "MIME (Multipurpose Internet Mail Extensions):
  20.    Mechanisms for Specifying and Describing the Format of Internet
  21.    Message Bodies" by Borenstein and Freed.
  22.  
  23.    This document also defines several additional optional functional
  24.    enhancements to IMAP2.
  25.  
  26.    [ ** Delete this note upon publication as an RFC **
  27.     The extensions discussed in this document are experimental and
  28.     subject to change.  It documents the state of these extensions
  29.     as of December 1992.  It is distributed for informational purposes
  30.     only.
  31.      In particular, additions may be made to IMAP2bis in subsequent
  32.     versions of this draft of the IMAP2bis document.  Persons planning
  33.     on implementing these extensions are STRONGLY URGED to get in touch
  34.     with the author before embarking on such a project.]
  35.  
  36.    The name of the resulting protocol is IMAP2bis.  IMAP2bis extends
  37.    but does not obsolete the base protocol described in RFC-1176.  A
  38.    few changes are made to the base protocol described in RFC-1176.
  39.    It is believed that no existing implementations are affected by
  40.    these changes; however, implementors may wish to verify that their
  41.    IMAP2 implementations are IMAP2bis compatible.
  42.  
  43.    Although the IMAP2bis functional extensions are separable from each
  44.    other based upon function, an RFC-1176 implementation is NOT IMAP2bis
  45.    compliant (as opposed to IMAP2bis compatible) unless it implements
  46.    ALL of the functional extensions and changes described here.
  47.  
  48.    Discussion and suggestions for improvement are requested.  Please
  49.    refer to the current edition of the "IAB Official Protocol Standard"
  50.    for the standardization state and status of this protocol.
  51.    Distribution of this memo is unlimited.
  52.  
  53.    This specification does not purport to apply to the IMAP3 protocol
  54.    described in RFC-1203.
  55.  
  56. Conventions
  57.  
  58.    Please refer to RFC-1176 for all conventions used in this document.
  59.  
  60.  
  61. I.a. MIME Command Extensions
  62.  
  63.    tag FETCH sequence data
  64.  
  65.       The FETCH command is extended as follows:
  66.  
  67.       FULL             Macro equivalent to:
  68.                       (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
  69.  
  70.       BODY            The body of the message.  The body is computed
  71.                       by the server by parsing the RFC 822 header and
  72.                       body into the component parts, defaulting various
  73.                       fields as necessary.
  74.  
  75.       BODY[section]   The text of a particular body section.  The
  76.                       section specification is a set of one or more
  77.                       part numbers delimited by periods.
  78.  
  79.                       Single-part messages only have a part 1.
  80.  
  81.                       Multi-part messages as assigned consecutive
  82.                       part numbers, as they occur in the message.
  83.                       If a particular part is itself multi-part, its
  84.                       parts must be indicated by a period followed by
  85.                       that part number within that nested multi-part
  86.                       part.  It is not permitted to fetch the text of
  87.                       a nested multi-part part.
  88.  
  89.                       A part of type MESSAGE also has nested parts,
  90.                       which are the parts of the MESSAGE part's body.
  91.  
  92.                       Every message has at least one part.
  93.  
  94.                       EXAMPLE: Here is a very complex message with its
  95.                       associated section specifications.
  96.                            1   TEXT
  97.                            2   BINARY
  98.                            3   MESSAGE
  99.                            3.1   TEXT
  100.                            3.2   BINARY
  101.                                MULTIPART
  102.                            4.1   IMAGE
  103.                            4.2   MESSAGE
  104.                            4.2.1   TEXT
  105.                       Note that there is no section specification for
  106.                       the Multi-part part itself.
  107.  
  108.  
  109. I.b. MIME Response Extensions
  110.  
  111.    * number message_data
  112.  
  113.       FETCH data
  114.               Data fetching is extended to add the following properties:
  115.  
  116.         BODY          An S-expression format list that describes the
  117.                       body of a message.  The body is computed by the
  118.                       server by parsing the RFC 822 header and body into
  119.                       the component parts, defaulting various fields
  120.                       as necessary.
  121.  
  122.                       Multiple parts are indicated by S-expression
  123.                       nesting.  In this case, instead of a body type
  124.                       as the first element of the list there is a nested
  125.                       body.  The last element of the list is the multipart
  126.                       subtype (mixed, digest, parallel, alternative, etc.).
  127.  
  128.                       The basic fields of a non-multipart body are in the
  129.                       following order:
  130.                         body type - an atom giving the content type name
  131.                           as defined in MIME
  132.                         body subtype - a string giving the content subtype
  133.                           name as defined in MIME
  134.                         body parameter list - an s-expression list of
  135.                           attribute/value pairs [e.g. (foo bar baz rag)
  136.                           where `bar' is the value of `foo' and `rag' is
  137.                           the value of `baz'] as defined in MIME.
  138.                         body id - a string giving the content id as
  139.                           defined in MIME.
  140.                         body description - a string giving the content
  141.                           description as defined in MIME.
  142.                         body encoding - a string giving the content
  143.                           transfer encoding as defined in MIME.
  144.                         body size - a number giving the size of that
  145.                           body in bytes.  Note that this size is the
  146.                           size in its transfer encoding and not the
  147.                           resulting size.
  148.  
  149.                       A body type of type MESSAGE and subtype RFC822
  150.                       contains, immediately after the basic fields,
  151.                       the envelope of the encapsulated message, its
  152.                       body structure, and its size in text lines.
  153.  
  154.                       A body type of type TEXT contains, immediately
  155.                       after the basic fields, the size of the body
  156.                       in text lines.
  157.  
  158.         BODY[section] A string expressing the body contents of the
  159.                       specified section.  This string is transmitted
  160.                       as 7-bit US-ASCII, encoded as according to MIME
  161.                       content transfer encoding.  The string is
  162.                       interpreted according to the content transfer
  163.                       encoding and the body type and subtype.
  164.  
  165.                       Note that 7-bit US-ASCII is the transport format
  166.                       and NOT necessarily the byte size or character
  167.                       set of the result.  The resulting data may be
  168.                       8-bit of some other character set or even binary!
  169.  
  170.  
  171. II.a. Mailbox Management Command Extensions
  172.  
  173.    The following extensions are in the area of mailbox management.  They
  174.    are intended to provide basic mailbox management services in a simple
  175.    (single server) configuration.  Mailbox management in more complex
  176.    environments is dealt with by a separate distributed management
  177.    protocol.
  178.  
  179.    tag FIND MAILBOXES pattern
  180.  
  181.       The FIND MAILBOXES command as described in RFC-1176 is hereby
  182.       more thoroughly defined.  This command returns the mailboxes
  183.       that the user has declared as being "active" or "subscribed."
  184.  
  185.       The restriction that FIND MAILBOXES does not return the name
  186.       INBOX is removed.  The name INBOX is returned by FIND MAILBOXES
  187.       if that name has been subscribed (see SUBSCRIBE MAILBOX below).
  188.  
  189.       The functionality is otherwise unchanged.
  190.  
  191.       The exact meaning of this is implementation-dependent, since
  192.       the concept of a set of `active' or `subscribed' mailboxes that
  193.       is preserved across sessions may not be meaningful for a
  194.       particular server or server implementation.  If the SUBSCRIBE
  195.       MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then
  196.       this command returns the list manipulated by those commands.
  197.  
  198.    tag FIND ALL.MAILBOXES pattern
  199.  
  200.       The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES;
  201.       however, it should return a complete list of all mailboxes
  202.       available to the user.  Data is returned as in FIND MAILBOXES.
  203.  
  204.       The special name INBOX is included in the output from
  205.       FIND ALL.MAILBOXES unless INBOX is not supported by this server
  206.       or for this user.  The criteria for omitting INBOX is whether
  207.       or not SELECT INBOX will return failure; it is not relevant
  208.       whether or not the user's actual INBOX resides on this or some
  209.       other server (see FIND MAILBOXES and SUBSCRIBE MAILBOX for a
  210.       mechanism for the user to identify that this is the real INBOX).
  211.  
  212.       If FIND ALL.MAILBOXES is implemented FIND MAILBOXES must also
  213.       be implemented, even if it returns the same information.  Also,
  214.       FIND ALL.MAILBOXES must, at least, return all the mailbox names
  215.       that are returned by FIND MAILBOXES.
  216.  
  217.       The exact meaning of this is implementation-dependent, since
  218.       the concept of a bounded or deterministic set of `mailboxes
  219.       available to the user' may not be meaningful for a particular
  220.       server or server implementation.
  221.  
  222.    tag FIND BBOARDS pattern
  223.  
  224.       The FIND BBOARDS command as described in RFC-1176 is hereby
  225.       more thoroughly defined.  This command returns the bboards
  226.       that the user has declared as being "active" or "subscribed."
  227.       The functionality is otherwise unchanged.
  228.  
  229.       The exact meaning of this is implementation-dependent, since
  230.       the concept of a set of `active' or `subscribed' bboards that
  231.       is preserved across sessions may not be meaningful for a
  232.       particular server or server implementation.  If the SUBSCRIBE
  233.       BBOARD and UNSUBSCRIBE BBOARD commands are implemented then
  234.       this command returns the list manipulated by those commands.
  235.  
  236.    tag FIND ALL.BBOARDS pattern
  237.  
  238.       The FIND ALL.BBOARDS command is similar to FIND BBOARDS;
  239.       however, it should return a complete list of all bulletin
  240.       boards available to the user.  Data is returned as in
  241.       FIND BBOARDS.
  242.  
  243.       If FIND ALL.BBOARDS is implemented FIND BBOARDS must also
  244.       be implemented, even if it returns the same information.  Also,
  245.       FIND ALL.BBOARDS must, at least, return all the bboard names
  246.       that are returned by FIND BBOARDS.
  247.  
  248.       The exact meaning of this is implementation-dependent, since
  249.       the concept of a bounded or deterministic set of `bboards
  250.       available to the user' may not be meaningful for a particular
  251.       server or server implementation.
  252.  
  253.    tag CREATE mailbox
  254.  
  255.       The CREATE command creates a mailbox with the given name.  This
  256.       command returns an OK response only if a new mailbox with that
  257.       name has been created.  It is an error to attempt to create a
  258.       mailbox with a name that refers to an extant mailbox.  Any error
  259.       in creation will return a NO response.
  260.  
  261.       Creating INBOX is not permitted.  If there is a primary or default
  262.       mailbox for this user, it MUST exist and be called INBOX; hence it
  263.       may not be created.  Otherwise, the name INBOX can not be used; see
  264.       section VI, "INBOX Requirement Loosened", for more details.
  265.  
  266.    tag DELETE mailbox
  267.  
  268.       The DELETE command deletes a mailbox with the given name.  This
  269.       command returns an OK response only if a mailbox with that name
  270.       has been deleted.  It is an error to attempt to delete a mailbox
  271.       name that does not exist.  Any error in deletion will return a
  272.       NO response.
  273.  
  274.       A server SHOULD NOT attempt to test that a mailbox is empty prior
  275.       to permitting deletion; this would prevent the deletion of a mailbox
  276.       which for some reason can not be opened or expunged, leaving to
  277.       possible denial of service problems.  Any such checking should be
  278.       left to the discretion of the client.
  279.  
  280.       Deleting INBOX is not permitted.
  281.  
  282.    tag RENAME oldmailbox newmailbox
  283.  
  284.       The RENAME command changes the name of a mailbox.  This command
  285.       returns an OK response only if a mailbox with the old name exists
  286.       and has been successfully renamed to the new name.  It is an error
  287.       to attempt to rename with an old mailbox name that does not exist
  288.       or a new mailbox name which already exists.  Any error in renaming
  289.       will return a NO response.
  290.  
  291.       Renaming INBOX is permitted.  A new, empty INBOX is created in its
  292.       place.
  293.  
  294.    tag SUBSCRIBE MAILBOX mailbox
  295.  
  296.       The SUBSCRIBE MAILBOX command adds the specified mailbox name to
  297.       the list of "active" or "subscribed" mailboxes as returned by
  298.       the FIND MAILBOXES command.  This command returns an OK response
  299.       only if the subscription is successful.
  300.  
  301.       If SUBSCRIBE MAILBOX is implemented then FIND MAILBOXES must also
  302.       be implemented, and FIND ALL.MAILBOXES should be implemented.
  303.  
  304.       Subscriptions should be preserved between sessions.
  305.  
  306.    tag UNSUBSCRIBE MAILBOX mailbox
  307.  
  308.       The UNSUBSCRIBE MAILBOX command removes the specified mailbox name
  309.       from the list of "active" or "subscribed" mailboxes as returned by
  310.       the FIND MAILBOXES command.  This command returns an OK response
  311.       only if the unsubscription is successful.
  312.  
  313.       If UNSUBSCRIBE MAILBOX is implemented then SUBSCRIBE MAILBOXES and
  314.       FIND MAILBOXES must also be implemented, and FIND ALL.MAILBOXES
  315.       should be implemented.
  316.  
  317.       Unsubscriptions should be preserved between sessions.
  318.  
  319.    tag SUBSCRIBE BBOARD bboard
  320.  
  321.       The SUBSCRIBE BBOARD command adds the specified mailbox name to
  322.       the list of "active" or "subscribed" bulletin boards as returned
  323.       by the FIND BBOARDS command.  This command returns an OK response
  324.       only if the subscription is successful.
  325.  
  326.       If SUBSCRIBE BBOARD is implemented then FIND BBOARDS must also
  327.       be implemented, and FIND ALL.BBOARDS should be implemented.
  328.  
  329.       Subscriptions should be preserved between sessions.
  330.  
  331.    tag UNSUBSCRIBE BBOARD bboard
  332.  
  333.       The UNSUBSCRIBE BBOARD command removes the specified mailbox name
  334.       from the list of "active" or "subscribed" bulletin boards as
  335.       returned by the FIND BBOARDS command.  This command returns an OK
  336.       response only if the unsubscription is successful.
  337.  
  338.       If UNSUBSCRIBE BBOARD is implemented then SUBSCRIBE BBOARDS and
  339.       FIND BBOARDS must also be implemented, and FIND ALL.BBOARDS
  340.       should be implemented.
  341.  
  342.       Unsubscriptions should be preserved between sessions.
  343.  
  344.  
  345. II.b. Mailbox Management Response Extensions
  346.  
  347.    No response extensions are made in the area of mailbox management.
  348.  
  349.  
  350. III.a. Cache Management Command Extensions
  351.  
  352.    RFC-1176 specifies that a server is not obligated to transmit data
  353.    in response to a FETCH command that it has already transmitted
  354.    earlier in the session.  This can place an unreasonable burden on
  355.    clients which lack the resources to maintain a local copy of the
  356.    state transmitted by the server during this session.  To address
  357.    this problem, the PURGE command has been defined.
  358.  
  359.    The previous exemption of texts made to this rule is hereby revoked
  360.    and replaced with this new mechanism.
  361.  
  362.    Servers which refrain from sending data previously sent MUST implement
  363.    the PURGE command.  Clients which do not cache all data sent from the
  364.    server MUST implement the PURGE command.  It can be assumed that any
  365.    server which returns BAD to any PURGE command does not exploit any
  366.    caching at the client.
  367.  
  368.    As of this writing, the only exploitation of client caching by known
  369.    server implementation is that some servers do not send EXISTS or
  370.    RECENT updates in response to a CHECK command under certain
  371.    circumstances.  The requirement that a client cache this information
  372.    is unaffected by the new PURGE functionality.
  373.  
  374.    PURGE STATUS sequence
  375.  
  376.       The PURGE STATUS command informs the server that the client has
  377.       deleted all information about the status (flags, internal date,
  378.       and RFC-822 size) of the specified messages from its cache.
  379.  
  380.    PURGE STRUCTURE sequence
  381.  
  382.       The PURGE STRUCTURE command informs the server that the client has
  383.       deleted all information about the structure (envelope and body)
  384.       of the specified messages from its cache.
  385.  
  386.    PURGE TEXTS sequence
  387.  
  388.       The PURGE TEXTS command informs the server that the client has
  389.       deleted all information about the texts (header, text, or body
  390.       parts) of the specified messages from its cache.
  391.  
  392.    PURGE ALWAYS
  393.  
  394.       The PURGE ALWAYS command informs the server that the client has
  395.       no capability to cache any data.  The server must re-send data
  396.       whenever requested by the client.
  397.  
  398.       Note: PURGE ALWAYS does not affect information returned by the
  399.       EXISTS and RECENT unsolicited responses.  Such information MUST
  400.       be remembered by even a non-caching client, since there is NO
  401.       guarantee that ANY command will return EXISTS or RECENT information
  402.       on demand.
  403.  
  404.    PURGE token sequence
  405.  
  406.       Any unknown subcommand of PURGE should be rejected with a NO
  407.       response instead of a BAD response.
  408.  
  409. III.b. Cache Management Response Extensions
  410.  
  411.    No response extensions are made in the area of cache management.
  412.  
  413.  
  414. IV.a. Mailbox Append Command Extensions
  415.  
  416.    tag APPEND mailbox string
  417.  
  418.       The APPEND command appends the string, which is in the format
  419.       of an RFC-822 message, to the specified mailbox.  If the append
  420.       is unsuccessful for any reason the mailbox must be restored to
  421.       its state prior to the append; no partial appending is permitted.
  422.  
  423.       Note that this functionality is unsuitable for message delivery,
  424.       because it does not provide a mechanism to transfer RFC 821 (SMTP).
  425.       envelope information.  Its primary purpose is to provide for a
  426.       `saved outgoing mail' mailbox which resides on the remote server.
  427.  
  428.  
  429. IV.b. Mailbox Append Response Extensions
  430.  
  431.    If the specified mailbox is open by a SELECT or BBOARD command, the
  432.    normal new mail action should be taken.
  433.  
  434.  
  435. V.a. Partial Text Fetching Command Extensions
  436.  
  437.    tag PARTIAL msgno RFC822 start_byte byte_count
  438.    tag PARTIAL msgno RFC822.HEADER start_byte byte_count
  439.    tag PARTIAL msgno RFC822.TEXT start_byte byte_count
  440.    tag PARTIAL msgno BODY[section] start_byte byte_count
  441.  
  442.       The PARTIAL command is equivalent to the associated FETCH command,
  443.       with the added functionality that only the specified number of
  444.       bytes, beginning at the specified starting byte, are returned.
  445.       Note as well that only a single message can be fetched at a time.
  446.       The first byte of a message, and hence the minimum for the
  447.       starting byte, is byte 1.
  448.  
  449.       Any partial fetch which attempts to read beyond the end of the
  450.       text is truncated as appropriate.  If the starting byte is beyond
  451.       the end of the text, an empty string is returned.
  452.  
  453.       The data is returned with the FETCH response.  There is no
  454.       indication of the range of the partial data in this response; thus
  455.       it is not possible to assume caching with PARTIAL data.  Any
  456.       knowledge of caching from a FETCH command of that data is
  457.       invalidated as with a PURGE command.  It is also not possible
  458.       to stream multiple PARTIAL commands of the same data item without
  459.       processing and synchronizing at each step, since each PARTIAL
  460.       fetch of data replaces any prior (PARTIAL) FETCH of that data.
  461.  
  462.       Note that when partial fetching it is possible to break in the
  463.       middle of a a line or a criticial sequence such as a BASE64
  464.       quadruple or QUOTED-PRINTABLE shift.  Implementations using
  465.       partial fetching should keep this in mind.  There is no requirement
  466.       that partial fetches follow any sequence; so if it turns out that
  467.       a partial fetch of bytes 1 through 10000 breaks in an awkward place,
  468.       it is permitted to continue with a partial fetch of 9987 through
  469.       19987, etc.
  470.  
  471. V.b. Partial Text Fetching Response Extensions
  472.  
  473.    No response extensions are made in the area of partial text fetching.
  474.  
  475.  
  476. VI. INBOX Requirement Loosened
  477.  
  478.    RFC-1176 required all server implementations to make available a
  479.    mailbox named "INBOX" on the server to be that user's primary mailbox
  480.    on that server.  Examples have come up of shared mailbox or bulletin
  481.    board only servers on which this requirement is unreasonable.
  482.  
  483.    The requirement is hereby modified as follows: SELECT's argument is
  484.    implementation-dependent; however the word "INBOX" is reserved to
  485.    mean a primary or default mailbox for this user, independent of any
  486.    other server semantics.  It is permitted for a server not to have an
  487.    INBOX if there is no concept of a primary or default mailbox for this
  488.    user.  The name "INBOX" MUST NOT be used for any other purpose.
  489.  
  490.  
  491. VII. Authentication Clarification
  492.  
  493.    RFC-1176 specifies that "until identity and access authorization have
  494.    been established, no operations other than LOGIN or LOGOUT are
  495.    permitted."  RFC-1176 specifies that authentication may be established
  496.    through the LOGIN command, or may have "already been accomplished
  497.    through other means, e.g. Kerberos."  RFC-1176 does not specify these
  498.    "other means" or how they are done.
  499.  
  500.    Pre-authentication is only possible when the connection to the IMAP2
  501.    service is made through some protocol other than a TCP connection to
  502.    port 143 and this protocol provides its own authentication mechanism.
  503.  
  504.    Although RFC-1176 gives Kerberos as an example of an alternate means
  505.    of authentication, it is not a good example of pre-authentication as
  506.    Kerberos does not provide a connection service.  A better example of
  507.    such a protocol is the BSD "RSH" protocol which provides authentication
  508.    through a "trusted host" facility.  Another example would be of a
  509.    manual invocation of an IMAP server from a logged-in timesharing job.
  510.  
  511.    A pre-authenticated IMAP server should recognize that authentication
  512.    has already happened, and enter the post-login state.  In its greeting
  513.    message, it should use the heretofore undocumented unsolicited reply
  514.    "PREAUTH" instead of "OK" to indicate that external authentication has
  515.    taken place.  For example, here is a pre-authentication scenario:
  516.  
  517.         S: * PREAUTH IMAP Server pre-authenticated as user `Smith'
  518.         U: A001 SELECT INBOX
  519.         S: * FLAGS (\Answered \Flagged \Deleted \Seen)
  520.         S: * 19 EXISTS
  521.         S: * 2 RECENT
  522.         S: A001 OK SELECT complete
  523.  
  524.    While a connection that is not pre-authenticated is currently
  525.    constrained to using the LOGIN command for establishing
  526.    authentication, that does not mean that authentication systems such as
  527.    Kerberos cannot be used.  While the examples show the "password"
  528.    argument to the LOGIN as being a short string typed in by the user,
  529.    this need not be the case.  If a server supports authentication via
  530.    Kerberos version 4, it may accept the string "@KERBEROS:" followed by
  531.    the hexadecimal representation of a Kerberos authenticator.
  532.  
  533.    For example, the following is a Kerberos login scenario (note that the
  534.    line breaks in the sample authenticator are for editorial clarity and
  535.    are not in a real authenticator):
  536.  
  537.    S: * OK Kerberos IMAP2 Server
  538.    U: a001 LOGIN smith @KERBEROS:040700414e445245572e434d552e4544550
  539.       038202c868f3890b377fc8266acc1bedb96b80d3fa76489898e74cd1c952dc
  540.       4003ea3428f29f1c470016cf5adc22f939e6deff2747254c1815d5b0b90d4c
  541.       5a2cba21eb0abe32f9acbf568d751bf4cc13f5ba4e6d82c638a8b5421
  542.    S: a001 OK [df84a4cb8323454f] Login OK via Kerberos
  543.  
  544.    The token in the brackets in the OK response is the Kerberos
  545.    authentication response, encrypted with the session key in network
  546.    byte order and an incremented checksum as in the usual Kerberos
  547.    procedure.
  548.  
  549.  
  550. VIII. Change to the Syntax of Dates
  551.  
  552.    With the impending end of the century and the necessity of having a
  553.    more general syntax for timezones than presently exists, the format
  554.    of IMAP2 internal dates has become inadequate.
  555.  
  556.    The BNF for the date syntax is hereby amended to be:
  557.  
  558.    date            ::= date_new / date_old
  559.  
  560.    date_new        ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz"
  561.  
  562.    date_old        ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
  563.  
  564.    In date_new, the year is now a 4-digit year, and the timezone is a
  565.    signed four-digit value of hhmm representing hours and minutes west
  566.    of Greenwich (that is, the amount that the given time differs from
  567.    Universal Time).  Subtracting the timezone from the given time will
  568.    give the UT form.
  569.  
  570.    Universal Time is expressed as "+0000".
  571.  
  572.    date_old is hereby declared obsolete, and its usage in new software
  573.    is STRONGLY discouraged.  However, client implementations MUST
  574.    recognize and properly parse it.
  575.  
  576.    RFC-1176 documents the argument to the SEARCH criteria BEFORE, ON, and
  577.    SINCE as being either "date" in the text and "string" in the BNF.
  578.    These SEARCH criteria arguments are hereby amended to be "day", with
  579.    the following syntax:
  580.  
  581.    day             ::= day_new / day_old
  582.  
  583.    day_new         ::= string in form "dd-mmm-yyyy"
  584.  
  585.    day_old         ::= string in form "dd-mmm-yy"
  586.  
  587.    day_old is hereby declared obsolete, and its usage in new software
  588.    is STRONGLY discouraged.  However, server implementations MUST
  589.    recognize and properly parse it.
  590.  
  591.  
  592. IX. COPY Command and the Unsolicited COPY Response
  593.  
  594.    RFC-1176 specifies that if the destination mailbox specified by a COPY
  595.    command does not exist, the server should create it.  With the advent
  596.    of the CREATE command, it is intended that this functionality will
  597.    eventually be deprecated.  Server implementations SHOULD continue to
  598.    create new mailboxes as needed with a COPY command, but SHOULD also
  599.    note to the user at the client, via an unsolicited OK response, that a
  600.    new mailbox was created.
  601.  
  602.    An unsolicited COPY response is mentioned in RFC-1176's documentation
  603.    of the COPY command, and in the BNF, but is not otherwise documented.
  604.    This response was intended to provide status of a COPY command, and
  605.    indicate how much of the COPY was done in the event of a COPY which
  606.    failed midway.
  607.  
  608.    This response was not implemented by many servers.  The definition of
  609.    the COPY command is hereby amended to REQUIRE that a COPY fully
  610.    complete the requested operation.  If this is not possible, then COPY
  611.    should do NONE of the requested operation, and back out of any partial
  612.    COPY as necessary.  This eliminates the ambiguity.
  613.  
  614.    The unsolicited COPY response is hereby declared obsolete.  It MUST
  615.    NOT be used in new server implementations.  Clients should ignore any
  616.    unsolicited COPY responses seen.
  617.  
  618.  
  619. X. Reiteration on the Unsolicited STORE Response
  620.  
  621.    Some server implementations return an unsolicted STORE response as a
  622.    result of a change caused by a STORE.  This was referenced in passing in
  623.    RFC-1064, but had already become obsolete.  The correct behavior is to
  624.    return an unsolicited FETCH response for both a FETCH and a STORE.
  625.  
  626.    As stated in RFC-1176, the unsolicited STORE response is obsolete.  It
  627.    MUST NOT be used in new server implementations.  Clients SHOULD treat any
  628.    unsolicited STORE responses as equivalent to unsolicited FETCH.
  629.  
  630.  
  631. XI. Anonymous Convention Established
  632.  
  633.    Some servers may wish to allow non-authenticated access to certain
  634.    mailboxes or bulletin boards.  The means by which this is accomplished
  635.    is with a LOGIN command using a userid of "anonymous".  A password is
  636.    still required; it is implementation-dependent what requirements, if
  637.    any, are placed upon the password.  It is also implementation-dependent
  638.    what access restrictions are placed on anonymous users.
  639.  
  640.    Since this is a convention, and not strictly a protocol extension or
  641.    change, implementations are NOT required to support the anonymous
  642.    convention in order to be considered IMAP2bis compliant.
  643.  
  644.  
  645. XII. Clarification of RFC822.HEADER
  646.  
  647.    RFC-1176 states that the concatenation of the strings returned by
  648.    fetching RFC822.HEADER and RFC822.TEXT is equivalent to the string
  649.    returned by fetching RFC822.  It was implicit that the delimiting
  650.    blank line would be included in RFC822.HEADER, because otherwise
  651.    there would be a leading blank line in RFC822.TEXT, but never
  652.    explicitly stated.
  653.  
  654.    The string returned by RFC822.HEADER includes the empty line that
  655.    delimits the header from the text in RFC-822.  In other words, all
  656.    non-null RFC822.HEADER strings end with a sequence of four ASCII
  657.    bytes: CR LF CR LF (0C 0A 0C 0A).
  658.  
  659.  
  660. XIII. SEARCH string extension
  661.  
  662.    The BODY and TEXT qualifiers in the SEARCH are hereby extended to
  663.    permit an RFC-1342 format multinational character string.  Due to
  664.    compatibility constraints, RFC-1432 format strings must be quoted.
  665.    For example:
  666.      SEARCH TEXT "=?US-ASCII?Q?leaping lizards?="
  667.    and
  668.      SEARCH TEXT "leaping lizards"
  669.    are equivalent.
  670.  
  671.  
  672. Formal Syntax
  673.  
  674.    The syntax of RFC-1176 is extended with the following rules.  Where
  675.    a rule is already defined in RFC-1176, this rule replaces it.
  676.  
  677.    The following syntax specification uses the augmented Backus-Naur
  678.    Form (BNF) notation as specified in RFC 822 with one exception; the
  679.    delimiter used with the "#" construct is a single space (SP) and not
  680.    a comma.
  681.  
  682.    append          ::= "APPEND" SP mailbox SP string
  683.  
  684.    body            ::= "(" body_structure ")"
  685.  
  686.    body_basic      ::= body_type SP body_subtype SP body_parameter SP
  687.                        body_id SP body_description SP body_encoding SP
  688.                        body_size_byte
  689.  
  690.    body_description::= nil / string
  691.  
  692.    body_encoding   ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/
  693.                        "QUOTEDPRINTABLE" / "X-UNKNOWN"
  694.  
  695.    body_id         ::= nil / string
  696.  
  697.    body_msg        ::= body_basic SP envelope SP body
  698.  
  699.    body_parameter  ::= nil / string
  700.  
  701.    body_section    ::= NUMBER / NUMBER "." body_section
  702.  
  703.    body_size_byte  ::= NUMBER
  704.  
  705.    body_size_line  ::= NUMBER
  706.  
  707.    body_structure  ::= body_basic / body_msg / body_text /
  708.                        1#body_structure SP body_subtype
  709.  
  710.    body_subtype    ::= nil / string
  711.  
  712.    body_text       ::= body_basic SP body_size_line
  713.  
  714.    body_type       ::= "TEXT" / "MULTIPART" / "MESSAGE" / "APPLICATION" /
  715.                        "AUDIO" / "IMAGE" / "VIDEO" / "X-UNKNOWN"
  716.  
  717.    create          ::= "CREATE" SP mailbox
  718.  
  719.    date            ::= date_new / date_old
  720.  
  721.    date_new        ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz"
  722.  
  723.    date_old        ::= string in form "dd-mmm-yy hh:mm:ss-zzz" ;; obsolete
  724.  
  725.    day             ::= day_new / day_old
  726.  
  727.    day_new         ::= string in form "dd-mmm-yyyy"
  728.  
  729.    day_old         ::= string in form "dd-mmm-yy" ;; obsolete
  730.  
  731.    delete          ::= "DELETE" SP mailbox
  732.  
  733.    fetch           ::= "FETCH" SP sequence SP ("ALL" / "FULL" /
  734.                        "FAST" / fetch_att / "(" 1#fetch_att ")")
  735.  
  736.    fetch_att       ::= fetch_att_other / fetch_att_text
  737.  
  738.    fetch_att_other ::= "BODY" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
  739.                        "RFC822.SIZE"
  740.  
  741.    fetch_att_text  ::= "BODY[" body_section "]" / "RFC822" /
  742.                        "RFC822.HEADER" / "RFC822.TEXT"
  743.  
  744.    find_option     ::= "MAILBOXES" / "BBOARDS" / "ALL.MAILBOXES" /
  745.                        "ALL.BBOARDS"
  746.  
  747.    istring         ::= string / RFC-1342 format multinational string
  748.  
  749.    msg_copy        ::= "COPY" ;; obsolete
  750.  
  751.    msg_data        ::= msg_exists / msg_recent / msg_expunge /
  752.                        msg_fetch / msg_copy / msg_store
  753.  
  754.    msg_fetch       ::= "FETCH" SP "(" 1#("BODY" SP body /
  755.                        "BODY[" body_section "]" string / "ENVELOPE" SP
  756.                        envelope / "FLAGS" SP "(" 1#(recent_flag
  757.                        flag_list) ")" / "INTERNALDATE" SP date /
  758.                        "RFC822" SP string / "RFC822.HEADER" SP string /
  759.                        "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
  760.                        string) ")"
  761.  
  762.    msg_store       ::= "STORE" SP "(" 1#("FLAGS" SP "(" 1#(recent_flag
  763.                        flag_list) ")" ) ")" ;; obsolete
  764.  
  765.    partial         ::= "PARTIAL" SP NUMBER SP fetch_att_text SP NUMBER SP
  766.                        NUMBER
  767.  
  768.    purge           ::= "PURGE" SP ("ALWAYS" / purge_option SP sequence)
  769.  
  770.    purge_option    ::= "STATUS" / "STRUCTURE" / "TEXTS" / token
  771.  
  772.    rename          ::= "RENAME" SP mailbox SP string
  773.  
  774.    search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
  775.                        "BCC" SP string / "BEFORE" SP day /
  776.                        "BODY" SP istring / "CC" SP string / "DELETED" /
  777.                        "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
  778.                        "ON" SP day / "RECENT" / "SEEN" /
  779.                        "SINCE" SP day / "TEXT" SP istring /
  780.                        "TO" SP string / "UNANSWERED" / "UNDELETED" /
  781.                        "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")
  782.  
  783.    subscribe       ::= "SUBSCRIBE" SP subscribe_opt SP string
  784.  
  785.    subscribe_opt   ::= "MAILBOX" / "BBOARD"
  786.  
  787.    unsubscribe     ::= "UNSUBSCRIBE" SP subscribe_opt SP string
  788.  
  789.    userid          ::= string / "anonymous"
  790.  
  791.  
  792. Implementation Status
  793.  
  794.    The University of Washington IMAP2bis distribution supports this
  795.    specification.  It can be obtained as mail/imap.tar.Z via anonymous
  796.    FTP from host ftp.cac.washington.edu; this is a compressed UNIX `tar'
  797.    format file.
  798.  
  799.    The University of Washington IMAP2bis distribution includes external
  800.    authentication using the Unix r-protocols.  Sites can enable or
  801.    disable rimap at their discretion; users can control rimap behavior
  802.    (provided the site has enabled it) by use of the standard .rhosts
  803.    and hosts.equiv files.  The anonymous convention is also included
  804.    for anonymous access to newsgroups is can also be enabled or disabled
  805.    on a site basis.
  806.  
  807.    A Kerberized IMAP2bis is in test at a few organizations, but is not yet
  808.    available for public release.
  809.  
  810.  
  811. Design Discussion
  812.  
  813.    IMAP2 as specified in RFC-1176 is a 7-bit protocol.  These extensions
  814.    make it possible to support 8-bit textual and binary mail through the
  815.    IMAP mode.
  816.  
  817.    Some thought was made on whether or not the body contents fetch should
  818.    return the decoded version of BASE64 and QUOTED-PRINTABLE sections, or
  819.    if there should be an option to get either the encoded or the decoded
  820.    form.  It was rejected on these grounds:
  821.     1) It makes the extensions unimplementable in any environment where
  822.        an 8-bit data stream is not possible.
  823.     2) It creates multiple ways of doing the same thing and hence
  824.        exponentially multiplies the possiblity of non-interoperable
  825.        implementations.
  826.     3) It introduces binary in the same data stream as commands, and
  827.        hence makes the protocol more vulnerable to synchronization
  828.        problems.
  829.  
  830.    If server-based decoding of BASE64 and QUOTED-PRINTABLE turns out
  831.    to be important, it should be transmitted out of band from the IMAP2
  832.    command stream.  This would have the necessary but unfortunate effect
  833.    of making the protcol more complicated.
  834.  
  835.  
  836. Unresolved issues
  837.  
  838.    The following issues are unresolved by IMAP2bis.  It is anticipated that
  839.    these will be dealt with in future specifications.
  840.  
  841.    The management capabilities of IMAP2bis are inadequate for complex
  842.    distributed mail configurations.  A separate specification, under
  843.    development at CMU, addresses this.
  844.  
  845.    The SEARCH command lacks MIME awareness, regular expressions, complex
  846.    logical qualifiers, etc.  This should be addressed in future versions of
  847.    the IMAP2 specification.
  848.  
  849.    It isn't clear that the RFC-1342 extensions to SEARCH are adequate for
  850.    the task.
  851.  
  852.    Message posting is orthogonal to the scope of a mail access protocol, and
  853.    it is undesirable for a number of reasons to shoehorn the two into a
  854.    single protocol.  However, issues of authentication and what to do with a
  855.    uni-channel link (e.g. IMAP over a dialup line) have come up.  The
  856.    IETF-REMMAIL working group is wrestling with these issues at this writing.
  857.  
  858.    Envelopes do not carry information such as resend data, newsgroups,
  859.    etc.  Newsgroups can probably be encoded within the existing address list
  860.    syntax.
  861.  
  862.    The question has come up as to whether or not there should be a way for
  863.    the server to build client browser lines.
  864.  
  865.  
  866. Acknowledgements
  867.  
  868.    Special thanks go to John Gardiner Myers, Chris Newman, Karl Jacob, Hisao
  869.    Nojima, Terry Gray, Adam Treister, Laurence Lundblade, and Mike Seibel for
  870.    their hard work in reviewing the present status of IMAP2, and for reaching
  871.    concensus and closure on a number of issues in record time.
  872.  
  873.    My thanks to everyone in the IETF-822 group for their hard work in
  874.    getting the Internet Message Bodies draft out the door, and
  875.    especially to Nathaniel Borenstein and Ned Freed for putting together
  876.    something we could all live with.
  877.  
  878.    Any mistakes, flaws, or sins of omission in this IMAP2bis protocol
  879.    extension are, however, strictly my own; and no endorsement on the
  880.    part of anyone is implied.
  881.  
  882.  
  883. Security Considerations
  884.  
  885.    Security issues are discussed in this memo only as far as authentication
  886.    for the purpose of accessing an IMAP2bis server are concerned.
  887.  
  888.  
  889. Author's Address
  890.  
  891.    Mark R. Crispin
  892.    Networks and Distributed Computing
  893.    University of Washington
  894.    Seattle, WA  98105
  895.  
  896.    Phone: (206) 842-2385
  897.  
  898.    EMail: MRC@CAC.Washington.EDU
  899.